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ABSTRACT 


The United States Marine Corps is implementing a new 
human resource system called the Total Force Administration 
System (TFAS). Enterprise and Enterprise Resource Planning 
(ERP) System implementations are reputed to be difficult 
because of the problems encountered by corporate America in 
the late 1990's. This thesis conducted a review of 
corporate enterprise system implementations looking for 
commonality in two areas: the most frequent problems 
encountered and key success factors. This thesis provides 
the TEAS leadership with issues of concern that require 
greater attention or research and with key success factors 
for the TEAS implementation. This thesis also reviewed and 
analyzed the preliminary architecture for the TEAS project. 
By leveraging the lessons learned from other 
implementations, it is hoped to increase the chances of 
success for this project and minimize implementation pain. 
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I.INTRODUCTION 


Chapter one discusses the purpose and content of this 
thesis. It also provides a brief overview of the context, 
premise, objectives, research questions, methodologies 
used, scope, limitations, assumptions, and definitions. 

A. CONTEXT 

This thesis conducts an analysis of the Marine Corps' 
future human resource enterprise system initiative called 
the Total Force Administration System or TFAS. 

The current system, the Marine Corps Total Force 
System (MCTFS), is a manpower and paper intensive system. 
The TFAS is the initiative that has sprouted from a review 
of the Marine Corps service model for providing pay and 
administrative support to individual Marines and to their 
commands. The result of this initial review has been the 
Marine Corps attempt to modify its current administrative 
(human resource) system by adding a self-service 
capability. Adding this capability will allow the Marine 
Corps to reengineer its business processes and eliminate 
the middleperson, the administrative clerk, between the 
individual Marine and his or her personal file. This self- 
service capability will streamline the data flow into the 
current backend system. This self-service capability is 
envisioned to include a Web portal and a call-center with 
interactive voice response (IVR). The Web portal and IVR 
will be the front end of a call center. The call center 
will be tied to the Marine Corps Total Force System 
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(MCTFS), the backend system for Marine Corps administration 
since the early 1980s. Administration capabilities will 
be spread over five levels vice the three levels currently 
used. The five levels will be: the individual Marine, 
small unit leadership, the command. Personnel 
Administration Centers (PACs), and higher 
headquarters/disbursing. 

The vision for TFAS as stated by Lieutenant Colonel 
(LtCOl) J.M. Peterson is "to markedly improve and modernize 
pay and administrative support while significantly reducing 
the number of Marines needed to provide that support." 
[Ref. 1] The individual Marine will be given more 
responsibility and the means for maintaining his own 
record. 

The TFAS must leverage existing and emerging 
technologies, reengineer administrative 
processes, conserve precious manpower resources 
and markedly improve the quality of 
administrative support. In the short term, the 
TFAS is designed to provide all Marines immediate 
access via multiple avenues to their personal 
administrative data. In the long run, TFAS is to 
become the enterprise system for conducting all 
personnel administrative business within the 
Marine Corps. The TFAS should improve the 
quality of administrative support provided to 
Marines throughout the wide spectrum of 
environments that we work in. [Ref. 1] 

Additionally, the TFAS must free up limited manpower, 
and provide a reach-back capability that makes personnel 
administration compatible with our doctrine of Operational 
Maneuver from the Sea (OMFTS), thus reducing the footprint 
physically required on the battlefield. This must be done 
while simultaneously keeping the Marine Corps on track for 
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compatibility with future Department of Defense (DoD) 
initiatives such as the Defense Integrated Military Human 
Resources System (DIHMRS) . 

The 15 major requirements for the TFAS are outlined 
in the preliminary assessment [Ref. 2] as: 

• Commanders, small unit leaders, and training 

managers must be able to collect, pass, and 
report pay and personnel information from the 
point of action 

• Commanders, small unit leaders, and training 

managers must be able to authenticate and upload 
selected transactions reflecting captured pay and 
personnel information directly into MCTFS without 
additional, intermediate-level processing. 

• Commanders, small unit leaders and training 

managers must have electronic download access to 
pay and personnel information. 

• Marines must be able to review pay and 
administrative information and to conduct 
associated transactions without having to be 
physically co-located with the service provider 
(administration unit). The importance of the 
geographic locations of the Marine needing 
support and the service provider must be 
eliminated. 

• The system must authenticate users' identities. 

• The system must allow users to sign documents in 
a paperless environment. 

• Marines must receive verification of their 
completed transaction with an estimated date on 
which that transaction will affect the Marines 
pay or other records. 

• Commanders must be informed of those transactions 
that are submitted through a self-service or Call 
Center capability. 

• Commanders must be able to collect, quality 
control (QC), and forward pay and personnel 
information to a regional Personnel 
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Administration Center (PAC) for final review, 
certification and processing. 

• Pay and personnel information forwarded from 

commanders must not require re-keying or 
manipulation once it arrives at the regional PAC. 

• The regional PAC must be able to receive and 

process transactions from the commanders they 
support and any commander in the Corps in case of 
contingencies. 

• The regional PAC must provide supported 

commanders with feedback reports that alert them 
to various information or action required 
relative to their Marines. 

• The paper service record book and officer 

qualification record must be eliminated. All pay 
and personnel information must be stored 
electronically in either the Marine's 

pay/personnel record in the MCTFS or in the 
Official Military Personnel File (OMPF) record 
maintained by the Commandant of the Marine Corps- 
Personnel Management Support Branch (CMC-MMSB). 

• The system must provide adequate information 

security to resist and otherwise prevent 
electronic attacks and other system misuses and 
abuses . 

• Technical knowledge, rules, and edits must be 
built into the system to minimize the training 
requirements for users and to enhance self- 
service actions. This also includes maximum use 
of plain language vice codes. 

An implied requirement is that the TFAS be compatible 
with current and future DoD initiatives. The DoD 

initiative with the most impact on the TFAS is the Defense 
Integrated Military Human Resources System (DIHMRS) 
initiative. The objectives and requirements for the DIHMRS 
are as follow. 

• Must be a fully integrated personnel and pay 
system that allows for one-time entry that 
updates all personnel and pay transactions. 
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• Include existing functionality of the 17 current 
legacy systems in use DoD wide. 

• Provide standard data and data requirements. 

• Provide flexibility to include service specific 
modules where needed 

• Use a commercial or government off the shelf 
software 

The TFAS implementation is currently scheduled to 
happen in four phases, spread over eight or more years. 
The TFAS is currently in the first stage, normally called 
the Concept Exploration Phase. However, the Marine Corps 
has already started to implement many of the requirements 
that would normally be accomplished in later phases in a 
traditional development or acquisition program. Thus, it 
would not be accurate to call Phase I of this program. 
Concept Exploration. With the TEAS initiative, the Marine 
Corps is attempting to leverage available technology and 
tie it to its existing technology to create a new human 
resources system that will be less manpower intensive and 
more scalable. 

The TEAS initiative will focus on the following areas 
to enable Marine Self-Service. There are other initiatives 
and process improvements that have been proposed for 
phasing into the program that are not directed toward 
Marine Corps Self-Service. The forms and processes that 
will be brought to the Web are: 

• Servicemen's Group Life Insurance (SGLI) 

• Income Tax W4 

• Tricare Enrollment 

• W-2 Eorm 

• DEERS Eorm 
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• Dependent Application Form 10922 

• Request for Waiver of Indebtedness 

• Combined Federal Campaign (CFC) Allotments 

• Reenlistment/Extension Requests 

• Lateral Move Requests 

• MCI Course Registration Requests 

• Separation/Retirement/Resignation Requests 

• Tuition Assistance Requests 

• Name Change Request 

• Master Brief Sheet Review 

• Benefits Waiver 

• Personal Awards Process Program 

• Audit capabilities such as: Basis Individual 

Record/Basic Training Record (BIR/BTR), Record of 
Emergency Data (RED), Latest Leave and Earnings 
Statement (LES), Career Retirement Credit Report 
(CRCR), and Basic Allowance for Housing) 

Certification. 

Eigure 1, 2, 3, and 4 below are diagrams that 
demonstrate and compare the current administration 
processes against the proposed processes after the TEAS 
implementation. Eigure 1 demonstrates how the new process 
eliminates steps, time, and the middleman from current 
processes. 


6 




Current Transaction Processing 



\ Marine vste ^ 

s 

\\ Marine waits ' 
\\ for available 
// administrator 

/ / 

\\ Admiristraor > 
\ \obtak«fofm{s) 
/ / atx) provides to, 
/ Manne / 

Maine N 
\ \ completes hard 
/ / copy form{ 3 ) > 

s\ AdministratcrX 
\ \ enters date \ 

// into system / 

t 

1 ' 

\ 

i ^ /. 

— 


Requres 
travel tirne-as 
moch as 30 
minutes on large 
bases 

Could result in 
wait time If 
administrator is 
unavailabte or 
assisting others 

Reles on paper 
forms-one event 
could require 
completing 3-4 
forms 

Many forms 
require duplicative 
information to be 
provided mulbple 
bmes 

Transcnption of 
forms completed 
by hand can result 
in data entry errors 
and delays 



LimKations 








Recommended Transaction Processing 


Marine aaess^sA 
IVR or W80 \ 

system / 


Marine records 
trans^sn 
*©renf 



Data uploaded \ 
tosysm ) 
inre^-time / 


- 

System accessrbte 

One transaction 

r ransactions no 

from home, base. 

entry triggers all 

longer need to be 

or deployed 

necessary data 

uploaded m 

location 

changes 

batches 


automatically 


Benefits 


Figure 1 . Comparison of Existing and Recommended Processing 

From Ref. [2] 


Figures 2 and 3 are my representations of the current 
process based on my last experiences as a Marine Corps 
administrator. These figures show some additional steps 
that are not in Figure 1 . 
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Current Administration Process 



Figure 3. Proposed Administration Process 



















Figures 4 and 5 are data flow diagrams that 
demonstrate how the number of levels of interaction with 
the system will increase from two to five with the TFAS 
implementation. The diagrams also show that the system 
will now have to be reengineered to add more approval 
safeguards into the system whereas the current system 
requires approval of data prior to input. 
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Figure 4. "As Is" Operational Architecture From Ref. [2] 


9 

















♦ 


♦ 


> 

♦ 


> 


♦ 


Request Queue 

ftocess TimsacticrLS 


Figure 5. "To Be" Operational Architecture From Ref. [2] 

Some of the processes that will be reengineered as a part 
of the TFAS include, separations, audits, and personal 
requests. 

As mentioned previously, the TFAS does not address any 
changes to the MCTFS. The Marine Corps believes that the 
MCTFS should and will be addressed as part of the DIHMRS 
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initiative and that the TFAS will work regardless of the 
backend system, whether that system is the MCTFS or the 
DIHMRS. The DIHMRS was scheduled to be operational by 
January 2002 but is currently behind the original schedule 
established by DoD. The DoD awarded the DIHMRS contract to 
PeopleSoft less than one month ago during August 2001. 
[Ref. 3] The article also states the following: 


PeopleSoft said the Defense Department would 
purchase the PeopleSoft 8 Human Resources 
Management System (HRMS) to consolidate several 
legacy applications for payroll and human 
resources. By consolidating the systems of all 
military branches and making records available to 
military personnel over the Internet, the Defense 
Department hopes to save money and improve 
efficiency in providing information to servicemen 
and women. DIHMRS will cut costs by allowing 
military personnel to easily check their own 
records around the clock without the intervention 
of the department's personnel in many cases. 

[Ref. 3] 

The Marine Corps contracted Klynveld Peat Marwick and 
Goerdeler (KPMG) consulting to analyze its current 
technical architecture and several administrative processes 
to determine inefficiencies and establish a baseline or the 
real costs in terms of time, manpower, and money. At the 
same time, PricewaterhouseCoopers was hired to document the 
best business practices of the Marine Corps and to 
recommend processes that should be considered for 
reengineering. According to the PricewaterhouseCoopers 
analysis, there is a commonality between the human resource 
functions and processes of the Marine Corps and other 
organizations that could be leveraged to facilitate easier 
process reengineering in those initiatives. 
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Additionally, the Marine Corps established a Quality 
Leadership Board and a Total Force Administration Steering 
Group to oversee and ensure success of the initiative. 
These two groups organized the best and brightest minds 
from the administrative community and the technical 
community to mirror the work being done by the consultants. 
They organized a test bed for new and promising ideas. The 
program manager for the Marine Corps, Lieutenant Colonel 
(LtCol) Gaskin says, "The success or failure of TFAS is 
dependent upon the Corps' program management approach, 
prioritization, scope, and management of operator 
expectations." [Ref. 4] 

B. PREMISE 

The premise of this thesis is that the TFAS initiative 
can benefit from looking at the challenges, mistakes, and 
lessons learned endured by corporate America. Applying 
those lessons learned to the TFAS implementation will 
increase the initiatives chance of success. Additionally, 
the initiative can benefit from a comparison of the 
proposed architecture for the TFAS against proven methods 
and standards of architecting an enterprise system. 

C. OBJECTIVE 

The areas that this thesis focuses on are enterprise 
architecture, enterprise system implementation, and how the 
Marine Corps can leverage the lessons learned from other 
enterprise implementations to ensure success of the TFAS. 
Therefore, the objective of this thesis is two-fold. The 

first objective is to evaluate enterprise resource systems 
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implementations of American corporations and to create a 
list of lessons learned from that could be applied to the 
implementation of TFAS in the Marine Corps. The second 
objective is to review the proposed architecture of the 
TFAS enterprise system. Architecture here refers to the 
set of processing components and processes of the system 
that represents a common approach. 

D. RESEARCH QUESTION 

The research conducted during the course of this 
thesis is intended to answer two main questions: 

• Can the Marine Corps leverage the lessons learned 
from other Enterprise Resource Planning (ERP) 
implementations to achieve a higher level of 
success with fewer problems? 

• Does the architecture of the TEAS as currently 
proposed have any apparent shortcoming? 

To better support the main questions, other questions 
that will be answered are: 

• What are the characteristics of a successful ERP 
implementation? 

• Are there any metrics that can be used to 
classify an ERP implementation as successful or a 
failure? 

• What are the common mistakes made during 

corporate ERP implementations ? 

• What lessons learned from American corporations 
can be applied to the TEAS? 
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• Historically, what are the major hurdles of an 
ERP implementation? 

• Are there any ERP implementations that closely 

resemble the TEAS plan? 

• Are there any deficiencies in the TEAS plan? 

• Is the TEAS concept a valid concept? Is it 

achievable ? 

• Is TEAS scalable? 

• Does TEAS fit into the future Joint DoD 

architecture? 

• What are the Key Success factors for TEAS? 

• Are there any overarching architectural or 

implementation issues that have been overlooked? 


E. SCOPE OF THESIS 

This thesis reviews the proposed architecture and the 
implementation of the TEAS. Concurrently, this thesis 
focuses on previous enterprise system implementations for 
similarities or for lessons learned that might be 
beneficial to the TEAS program management. This does not 
include a detailed analysis of individual or internal 
Marine Corps Personnel Administration or the TEAS 
processes. Additionally, this thesis will also make 
recommendations as to areas of further thesis study that 
could benefit the TEAS implementation. 
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F. LIMITATIONS OF THESIS 

Literature reviewed for the TFAS in this thesis were 
preliminary documents on preliminary documents and thus 
many topics are mentioned in concept only without details 
being provided in the actual documentation. Some of the 
issues that were glanced over include security, 
communication platform (s), and design architecture (s) . I 
was unable to acquire copies of the formal technical 
architecture study to give a complete analysis of the TFAS 
architecture. Therefore, I reviewed the preliminary 
architectural documents that were provided. Additionally, I 
have been unable to contact my Marine sponsor to clarify 
questions or to gain additional information. This thesis 
will proceed with the information as contained in the 
aforementioned preliminary documents. 

This thesis will not examine in detail the call center 
or IVR technology proposed by the TFAS. Call center and 
interactive voice response technology are both mature 
technologies with histories of smooth implementations. 
Both of these topics could however be included in follow-on 
research . 

G. ASSUMPTIONS 

This thesis assumes that the baselines established by 
KPMG and PricewaterhouseCoopers to be accurate and that all 
information posted on the official TFAS Website or provided 
by the program manager to be the official, latest, and most 
accurate information on the TFAS initiative. The baselines 
revolve around costs and benefits of the current system 


15 



upon which cost-to-benefit analysis of the alternatives 
were developed. 


H. METHODOLOGY 

This thesis will utilize the archival research method. 
The archival research method involves analyzing case 
studies and articles of Enterprise Resource Planning (ERP) 
system implementations in American corporations. Case 
studies are evaluated for similarities to the TEAS 
initiative and for general lessons learned that possibly 
could apply. 


I. DEFINITIONS AND ABBREVIATIONS 


The following definitions and abbreviations are 
defined as found in the TEAS documentation for the purpose 
of consistency. 

Architecture: structure of components, their 
relationships, and the principles and guidelines 
governing their design and evolution over time. 

[Ref. 5] 

Defense Integrated Military Human Resources 
System (DIMHRS) : DIMHRS is to provide a fully 
integrated military personnel and pay capability 
for all Components of the Military Services of 
the DoD to overcome shortcomings in legacy 
systems. [Ref. 2] 

E-business: improves business performance by 
using electronic information technologies and 
open standards to connect suppliers and customers 
at all steps along the value chain. The early 
stages of a company's e-business effort are 
almost always focused on reaching the customer. 
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the later stages on streamlining value-chain 
activities to deliver more value to the customer. 
[Ref. 6] 


Electronic Data Interchange (EDI) : EDI represents 
an early form of e-commerce built on essentially 
proprietary technology. Available long before the 
Internet achieved wide usage, EDI attempted, but 
failed, to become a computing standard that would 
allow non-compatible computers to share 
information. Today, the Internet combined with e- 
commerce is replacing it. [Ref. 7] 

Enterprise Resource Planning (ERP) : integrates 
the management functions within a company such as 
logistics, financial and human resources/payroll 
to enable enterprise-wide management of 
resources. [Ref. 6] The term "information 
resources management" is more appropriate for the 
military. 

Extensibility: The ability to extend an 
application to other enterprise systems; 
specifically the data warehouse. [Ref. 6] 

Information Resources Management: the process of 
managing information resources to accomplish 
agency missions. The term encompasses both 
information itself and the related resources, 
such as personnel, equipment, funds, and 
information technology. [Ref. 8] 

Joint Technical Architecture (JTA) : Identifies a 
common set of mandatory information technology 
standards and guidelines to be used in all new 
and upgrade acquisitions. [Ref. 2] 


Marine Corps Total Force System (MCTFS) : The 

MCTES is an integrated personnel and pay system. 
The Einance Systems Activity (ESA) at the Kansas 
City Center maintains the MCTES central database, 
which contains all of the MCTFS data elements. 
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This file is commonly referred to as the Central 
Master File (CMF). The CMF is comprised of more 
than 500,000 records containing specific data 
file elements of all Active/Reserve Marine 
personnel. These records are available to 
commanders and administrators throughout the 
Marine Corps for pay purposes, personnel 
management, or personnel management reporting. 
Use of this information facilitates procurement, 
training, assignment/mobilization, promotions, 
budget preparation, and pay service. [Ref. 9] 

Marine OnLine (MOL) : The MOL was envisioned as a 
way to strengthen the Marine Corps community, to 
enhance communication among every member of the 
enterprise, and to build a sense of connectivity 
that extends beyond geographic boundaries. 
Similar in concept to popular commercial Web- 
based services, the MOL is a Web-based system 
that facilitates the collection, organization, 
processing, and presentation of information. 
[Ref. 2] 

On-Line Diary System (OLDS) : OLDS is an 
input/output (I/O) system that supports 
Headquarters Marine Corps (HQMC), other higher 
headquarters elements, and their supporting 
establishment (e.g., non-Fleet Marine Force (FMF) 
commands). The system requires on-line 
connectivity to the mainframe-processing site at 
the mega center in St. Louis, Missouri. OLDS is a 
class IB system that provides a primary method of 
data entry into MCTFS. OLDS is a self-prompting 
system that allows the operator to choose various 
commands for data entry and retrieval. This allows 
the MCTFS diary and payroll transactions to be 
prepared, reviewed, deleted, certified, 
decertified, and printed. [Ref. 9] 

Operations Architecture: Operations architecture 
is a combination of tools, support services, 
procedures, and controls required to keep a 
production system up and running well. [Ref. 10] 

Operational Data Store-Enterprise (ODSE): 
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Operational Data Store (ODS) is an infinitely 
extensible, universal repository that contains 
functionally independent, functionally dependent, 
relational, hierarchical and aggregate data. ODS 
data is both current and historical and is 
stored, normalized, on the ODS server. This 
relational architecture is a staging area that 
supports data quality assurance, data mining and 
the production and management of data warehouses, 
data marts, new application databases, and feeds 
to other organizations. There is no user access 
to the ODS. [Ref. 11] 

Technical Architecture Framework for Information 
Management (TAFIM): The TAFIM is a set of 

documents produced by DoD to guide information 
systems toward open systems architecture. It 
provides the services, standards, design 
concepts, components and configurations that can 
be used to guide the development of technical 
architectures. [Ref. 2] 

Total Force Administration System (TFAS) : The 

TFAS initiative is a comprehensive effort to 
modernize the Marine Corps service model for 
providing pay and administrative support to 
commanders and Marines. This modernization 
effort includes a review of the role of the 
commander, the role of the individual Marine, 
organizational structure, processes and 
technology. [Ref. 4] 

Unit Diary/Marine Integrated Personnel System 
(UD/MIPS) : The commander's personnel and pay 
reporting and retrieval system that can be used 
from any location worldwide. The UD/MIPS is a 
state-of-the-art application that is scaleable to 
support the entire spectrum of reporting 
environments -- for both the active and reserve 
components of the Marine Corps. [Ref. 9] 
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II. HISTORY OF ENTERPRISE SYSTEMS 


"Computing has always been about extending human 
capabilities," says Mark Goodyear. [Ref. 10] Figure 6 
below is a graphical representation of the advances 
computing has made over the past 40 plus years, with at 
least one major platform in each decade. 
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Figure 6. History of Computer Systems From Ref. [10] 


A. BATCH COMPUTING 

The 1960's were the decade of batch computing. In 
batch computing, the system would process a group of 
transactions submitted together without user intervention. 
At the end of the processing, at some point, the computer 
would provide a report about the batch and list any errors. 
The report (s) would be batch printed on a daily or 

scheduled basis. Any items listed on the batch report as 
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errors would have to be resubmitted after proper research 
and correction of the error. 


B. ONLINE TRANSACTIONS 

The 1970's were the decade of on-line transactions. 
Online transactions allowed the user to submit transactions 
one at a time and receive immediate verification as to the 
success or failure of the transaction. Additionally, 
online transactions allowed all concerned to know the 
impact of the transaction. This changed the workflow of 
business and had an impact of how business was conducted. 
Later in the decade, the advent of on-line interactive 
systems allowed for businesses to communicate internally 
and with each other through wide area networks which had 
its beginning in this decade also. 

C. DATABASES AND DATABASE MANAGEMENT SYSTEMS 

The 1980's was the decade of databases and database 
management systems (DBMSs). Databases and database 
technology had been used, developed and implemented by 
corporations in the 1970's, but it was not until the 1980's 
that corporations began attempting to share data across 
organizational and application boundaries. [Ref. 10] 
Database technology did not change the way business was 
conducted per se; what it did for business was to make it 
more convenient to access data and "ensure it was updated 
while maintaining the integrity of the data." [Ref. 10] Up 
to this point, large database systems were usually written 
in COBOL; adding a field to a record or changing the byte 
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length of a data field required major overhaul. The DBMSs, 
particularly relational ones, eliminated that problem and 


enabled a lot more prototyping. This was only a back- 
office improvement and did not change the interface with 
the system. 

D. CLIENT/SERVERS 

The 1990's ushered in the decade of client/server 
technology. The implementation of client/server technology 
represented a major fundamental change in computing. The 
first change with client/server computing was that a 
transaction could now be processed on a keystroke-by- 
keystroke basis, which represented a change in the level of 
interaction between the user and the computer. Secondly, 
client/server computing facilitated communication in 
workgroups on local area networks (LAN) at speeds of 100 to 
1000 times that of wide area networks (WAN). [Ref. 10] 

In client/server computing, there are usually multiple 
processors: a workstation for making an entry and then 
multiple servers, in which transactions are processed 
across and finally several databases that updated to 
reflect the transaction. There is typically a three-level 
hierarchy of servers. The first level is the workstation, 
the middle level is the work group server, and the highest 
level is the enterprise server. A two-level hierarchy can 
also suffice in a client/server environment in which the 
workstation interacts directly with the enterprise server 
or mainframe. 
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E. 


NETCENTRIC/NETWORK-CENTRIC COMPUTING 


The promising new platform for the first decade of the 
new millennium seems to be netcentric or network-centric 
computing. Some of the new capabilities that promise to 
revolutionize computing in the netcentric environment are 
the use of browsers to create universal clients, the 
establishment of direct supplier-to-customer relationships, 
the ability to share richer documents than at any other 
time in history, and application version checking and 
dynamic update. [Ref. 10] 

Netcentric computing is a natural evolution of 
client/server technology best represented by a mathematical 
formula, Mark Goodyear [Ref. 10] states as, 

"Netcentric = Cllent/Server + Reach + Content" 

This formula shows netcentric computing as 
client/server computing with the new and improved 
capabilities of "reaching, interacting, communicating, 
transacting, and partnering with more entities in more 
locations; and there are new and richer forms of content 
being published, interacted with, or transacted." [Ref. 10] 



III. 


BACKGROUND 


A. HISTORY 

The Commandant of the Marine Corps (CMC) made the 
decision in 1997 to cut the manning level of the Marine 
Corps' administrative occupational specialty by over 1000 
billets. The decision was made based on recommendations 
that came from a General Officer's symposium and a force 
structure review of the Marine Corps. [Ref. 1] The 
recommendations were based on two primary facts or 
statistics that came from the review. First, most combat 
units were being staffed under targeted goals both during 
deployments and especially after returning from scheduled 
six-month deployments. Additionally, often Marines were 
being recycled from units returning from deployments to 
units going out on deployment or being sent on deployments 
with other units ahead of their deployment schedule in 
order to back fill vacant billets. The second factor was 
the size of the Marine Corps administrative community. In 
1997 between 9,000 and 10,000 administrators serviced 
approximately 175,000 Marines, a ratio of 1:19, whereas 
corporate America's average ratio was 1:68. [Ref. 9] 

It was an obvious conclusion that there must be some 
way to make Marine Corps administration more efficient. 
However, at the time that the decision was made, there was 
no clear-cut, preplanned vision on how to make this happen 
in the Marine Corps or how to redistribute the workload 
within the now smaller administrative community. 
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It just so happened that the right technology and the 
right technical personnel, along with the oversight boards 
setup by CMC were in place to envision the TFAS. 

During the fall of 1997, I Marine Expeditionary 
Force (MEF) and Marine Forces Reserve (MarForRes) 
began planning to test the concept of 
consolidating personnel administration services 
above the traditional battalion/squadron level. 

These tests were developed in response to the 1997 
Force Structure Review Groups ' (FSRG) 
recommendations to seek improved methods of 
performing administration while reducing the size 
and composition of the 01 occupational field. 

These tests were also designed to exploit the 
availability of improved technologies (tools, 
systems and solutions) . [Ref. 12] 

Additionally, the Marine Corps contracted with KPMG 
consulting to analyze its technical architecture and 
administrative processes to determine which processes would 
yield the most savings in time, manpower, and cost. 
PricewaterhouseCoopers was hired to conduct a best business 
practices analysis of Marine Corps Personnel Administration, 
an analysis of corporate better business practices and 
finally to deliver a Personnel Administration alternatives 
and cost-benefit analysis to the Corps by May 1999. 

The backbone of the Marine Corps administrative 
system is the Marine Corps Total Force System (MCTFS). The 
MCTFS is proprietary back office mainframe and server 
technology from the early 1980's, which contains integrated 
personnel and payroll data for active, reserve, and retired 
Marines. 

The two means of entering or retrieving data from MCTFS 

are the On-Line Diary System (OLDS) and the Unit 

Diary/Marine Integrated Personnel System (UD/MIPS). While 
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these systems provide commanders and personnel 
administrators with personnel and pay data, information is 
not readily accessible to the Marine. This system relied 
heavily upon administrators and thus creating inefficiencies 
such as : 

• Increased processing time and backlog 

• Increased data entry error in transferring 
information from paper-based forms. 

• Degraded service to Marines and commanders. 

• Increased labor costs in the OlXX (Admin) 
Occupation Field (OccFld) because of the need 
for administrators to support 100 percent of 
personnel transactions. [Ref. 9] 

The implementation of the MCTFS predates the rapid 
growth of client/server technology, automated workflow 
functionality and the ubiquity of Web-based applications. 
The current front-end system used with the MCTFS is the 
UD/MIPS that is based on batch technology. The decision to 
undertake the TFAS initiative provides the Marine Corps with 
significant opportunities to automate and streamline its 
personnel administration system. The TFAS, as discussed in 
this thesis is essentially a new front-end system for MCTFS. 
It will function as the foundation of a self-service center, 
with a 24-hour call center, and interactive voice response 
(IVR) telephony Web-based applications. [Ref. 9] The 19 
business processes have been selected for reengineering as 
part of the new streamlined data flow process. 

Figure 7 below is a diagram of the current environment. 
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Figure 7. Current Environment From Ref [2] 

B. CURRENT SITUATION 

The TEAS is still in phase one, which is scheduled to 
last through fiscal year 2002 (September 30, 2002) . 
Administrative Marines have already been consolidated from 
the battalion and squadron level to the regimental and group 
level. [Ref. 13] An interim set of standardized tools and 
processes have been deployed Corps wide. Other things 
scheduled for completion during phase one are the 
development of a technology acquisition strategy and 

establishment of Military Construction (MilCon) 
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requirements; and the completion of the technical 
architecture plans (scheduled to be completed by end of 
FYOO) . The Marine Corps plans to use an Abbreviated 
Acquisition Program profile to acquire the TFAS. The TFAS 
is currently budgeted at $12.8 million and with a request 
for $11.6 million in FY02. [Ref. 1] 

The TFAS leadership after reviewing the options 
presented by the PricewaterhouseCoopers analysis has chosen 
alternative one as the best option. The Marine Corps did 
not, however, contract with PeopleSoft as the contractor for 
the project as the analysis recommended, choosing instead to 
tackle the front-end in house. 

It should be noted that alternative two was the option 
with the greatest cost to benefit ratio. [Ref. 9] However, 
each of the options was less expensive than the status quo, 
due to the manpower intensiveness of the current system. 


Alter¬ 

native 

Description 

One 

Maintain the MCTFS and implement self-service 
technology. This alternative includes developing 
Web-based applications and interactive voice 
response (IVR) telephony to enable individual 
Marines to conduct routine transactions without 

assistance from an administrator. These new 
applications would be integrated with the 
existing MCTFS. This alternative also includes 
developing a shared-service call center for 
Marines who require additional assistance. 

Two 

Replace MCTFS with a Human Resources Information 
System (HRIS) and implement self-service 
technology. This alternative includes replacing 
MCTFS with a COTS client/server HRIS. Also, it 
includes developing Web-based applications and 
IVR telephony to enable individual Marines to 
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conduct routine transactions without assistance 
from an administrator. These new applications 
would be integrated with the HRIS. This 
alternative also includes developing a shared- 
service call center for Marines who require 
additional assistance. 

Three 

Maintain MCTFS and outsource the management of 
self-service technology. This alternative 
involves selecting an outsourcing contractor to 
provide Web-based applications and IVR telephony 
to enable individual Marines to conduct routine 
transactions without assistance from an 
administrator. The contractor would provide call 
center services for Marines who require 
additional assistance. 


Table 1. Summary of Alternatives From Ref. [9] 

The Marine Corps has invested approximately $1.1 million in 

TFAS over the past two fiscal years. 

1. Marine OnLine (MOL) 

The Marine Corps has established the foundation 
of a Web-based self-service environment through 
the creation of Marine on Line (MOL). The MOL is 
the portal or communications medium that will 
allow Marines regardless of location to access 
and interface electronically with their personnel 
data via any standard web browser connected to 
the Internet. The MOL has been designed to 
employ state-of-the-art security architecture to 
include Lightweight Directory Access Protocol 
(LDAP) and Secure Socket Layer (SSL). 
Appropriate technologies such as Public Key 
Infrastructure (PKI) combined with the proper 
business rules will authenticate the identity of 
the individual submitting information for 
processing. Verification procedures will ensure 
the validity of the information being submitted. 

[Ref. 2] 


Information from Marine service records have already 
been linked to the MOL Website http://www.mol.usmc.mil/. 
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with a UserlD and password. Marines can go online now and 
view or query selected data such as personal, training, and 
service information about themselves and their units. The 
MOL will be linked to the DFAS Employee/Member Self-Service 
(E/MSS) site and the Marine Corps Operational Data Store- 
Enterprise (ODSE). The Marines have reengineered processes 
in 19 areas that are being prepared for the TEAS and the MOL 
Website. These modules are being tested in the Eleet Marine 
Eorce (EME) and will be implemented in modules once TEAS 
architecture has been implemented throughout the enterprise. 

It should be stated that the Marine Corps was able to 
start the TEAS initiative in EYOO because of its cost and 
schedule strategy which will allow the leveraging of current 
resources allocated to UD/MIPS, MCTES, and TEAS. [Ref. 2] 

2. Information Technology Directorate, Kansas City 
Center (IDT-KCC) 

The TEAS leaders chose ITD-KCC as the integrator for 
the TEAS project. This decision was made based on ITD- 
KCC's familiarity with the MCTES and UD/MIPS and ITD-KCC's 
established service record of meeting the demands of the 
Marine Corps pay and personnel communities while providing 
cost effective service. [Ref. 2] The ITD-KCC was once a 
Marine Corps Central Design and Programming Activity. The 
ITD-KCC created the MCTES that is considered the only 
integrated personnel and pay system within the DoD and one 
of the most technologically current personnel and pay 
client-server systems, UD/MIPS, found in the DoD. 
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3. 


Software Development 


The TFAS will use the existing configuration control 
board for the MCTFS and the UD/MIPS that consists of ITD- 
KCC, the Marine Corps and DFAS-KC. Software will be 
released during the normal MCTFS and UD/MIPS software 
release schedule of April and October of each year. The TFAS 
has been broken down into 19 separate work packages that 
will be phased in by fiscal year. Preliminary documents do 
not specifically say who will create the software for the 
TFAS. Regardless of who creates the software, there are two 
concepts that are critical to interoperability when writing 
this software. 

a. Modularity 

Modularity is important when writing software 
because it can isolate system and hardware platform 
dependencies. Modularity allows the isolation of 
operations or processes that are likely to change, 
isolation of data management, and the isolation of input 
and output, which is what the TFAS wants to change most. 
Modularity supports encapsulation, which can result in 
greater cohesiveness. Cohesion is defined here by how 
closely the operations are related in a module and by the 
functionality of the unit. The best cohesion is functional- 
each module or unit has only one task. [Ref. 14] 

ib. Loose Coupling 

Highly coupled modules traditionally have more 
errors and are more costly to maintain. Therefore, loose 
coupling is considered the best practice. "Good coupling 
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between units is loose enough that one unit can easily be 
used from another." [Ref. 14] Coupling refers to the 
strength of a connection between two modules or units of 
connection. 

4. Risks 

Managers for the TFAS have identified the risks 
associated with the initiative and developed a risk 
mitigation strategy. Risks identified include the 

following: [Ref. 2] 

a. Project Risks 

• TFAS relationship to the Defense Integrated 
Military Human Resources System (DIHMRS) 

• Available funding for out years 

• Selection of a vendor(s) and 

• Ability to execute the plan 

ib. Technical Risks 

• Technical architecture design 

• Infrastructure support 

• The infusion of new technology into the 
current service model 

c. Development Risks 

• The software development environment 

• Integration with current initiatives 
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Figure 8. Primary Baseline Technology for Personnel 
Administration From Ref. [9] 


C. DIFFERENCES BETWEEN THE MILITARY AND CORPORATE AMERICA 

There are differences between corporate America and 
the military that can effect how an ERP or enterprise 
system is implemented. It is important to highlight these 
differences prior to moving to the analysis portion of this 
thesis. Figure 9 below illustrates that the information 
systems direction and computing architecture for an 
organization is derived from its organizational direction 
and requirements. 
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■ Mission 

■ Strategic Objectives 

■ Strategies 

■ Computing Architecture 

■ Policies and Responsibilities 

■ Annual Objectives 

■ Service Architecture 

Figure 9. Current IS Situation Summary From Ref. [15] 


It is very obvious that the military has a different 
mission and strategic objective than corporate America. 
Corporations are in the business of making money. There 
interests in implementing an ERP, e-business or enterprise 
information systems, will be centered on building corporate 
wealth. This can involve increasing consumer satisfaction, 
consumer loyalty, and giving contractors and consumers 
outside of the enterprise access to information found in 
applications and databases. The military does not sell a 
commercial product. Our customer is usually someone within 
the enterprise. 

The biggest difference between the military and most 
organizations are the environment and external requirements 
in which our systems must be able to operate. Corporate 
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America does not have to worry about a potentially 


constantly changing hostile environment, such as a 
deployment or in a combat zone in the middle of the desert. 
Our garrison architectures often look alike with the 
exception that the military must build redundancy into 
their system and account for being able to communicate with 
minimum bandwidth in situations such as those mentioned 
previously. 


Military systems often have long acquisition times and 
cycles because of the Congressional budget and oversight 
process. The military often does not use cutting edge 
technology. In the information systems arena, even when 
the military attempts to use cutting edge technology, by 
the time the project has been completed, the technology is 
no longer cutting edge. There have been recent exceptions 
to this rule under abbreviated acquisition rules. The 
military does not have competitors in the traditional sense 
and thus has more of a focus on increased efficiency and 
quality. 

Both military and corporate organizations share the 
same type of concerns surrounding sound architectural and 
project implementations. However, corporations normally 
try to implement IT changes as quickly as possible, the 
military normally takes a slower, deliberate approach to 
implementation. The biggest reason for this is that the 
corporation normally considers opportunity costs as a part 
of the equation when determining the actual implementation 
costs. The military normally wants the system to work at 
the end of the implementation on or near budget. Different 
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information, external and business requirements lead to 
different implementation times. 

There are different security considerations between 
military and other organizations. Access to military 
systems are usually concerned with allowing access only to 
personnel within the enterprise. However, most 
corporations have multi-tiered relationships with 
customers, potential customers, contractors, suppliers, and 
employees involving international and multilingual 
requirements. The military has security concerns that 
will require stringent user identification and 
authentication prior to access to any portion of the 
enterprise system. Thus while corporate America is ensuring 
that their platforms will allow for the connection of their 
systems to other suppliers and customers, the military 
builds their systems to prevent unauthorized access to 
their systems. This difference is the reason that military 
systems must use modularity and loose coupling in the 
majority of their systems. 

The military lifecycle for systems and programs is 
different than corporate America. Example, when corporate 
America purchases a computer, often that computer will be 
upgraded or replaced in 18-month cycles; the military will 
keep this same computer in its inventory for many years, 
sometimes for as long as it is functional. It is, however, 
more risky for most organizations to upgrade their software 
than it is to upgrade their hardware. 

According to PricewaterhouseCoopers, the Marine Corps 
personnel administration shares similar functions with 
corporate human resource systems many of which have been 
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modernized to include a self-service capability. [Ref. 9] 
This suggests that a self-service capability for the Marine 
Corps personnel administration is a natural evolution. The 
differences between the two are the processes and 
environmental factors previously mentioned. 
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IV. LESSONS LEARNED FROM CORPORATE ERP 


IMPLEMENTATIONS 


The information gathered and compiled for this chapter 
comes from books, case studies, and magazine articles 
related to e-business, e-commerce, supply-chain management, 
ERP, and other enterprise information system 
implementations over the past couple of years. I attempted 
to capture the mistakes, problems, successful strategies, 
and hints that recurred most in my research or that stood 
out as being relevant to the TEAS. Keeping in mind the 
differences between corporate America and the military that 
were stated previously, the lessons learned that appear in 
the body of this chapter will not all apply to the TEAS 
implementation. Einally, I will focus on compiling a list 
of Key Success Eactors for the TEAS implementation. 

It should be noted that ERP projects outside of the 
military have a reputation for running over cost and behind 
schedule. However, there are numerous examples over the 
past two years of ERP implementations that have been both 
within cost and schedule. Web or Internet based 
implementations have become extremely popular during this 
time . 


A. COMMON MISTAKES 

The most common mistakes that ERP vendors, major 
corporations, and other organizations have reported from 
enterprise-wide information system implementations follow. 
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These mistakes are not listed in order of importance or 
frequency of occurrence. 


Companies often choose ERP packages simply from 
the functional requirements of the business 
without considering the company's ability to 
migrate to the package. [Ref. 10] 

Most systems focus primarily on either the 
planning requirements (on the front end) or the 
time and attendance/data collection (on the back 
end). [Ref. 6] 

An organization does not know its own system. 
Integration of existing systems is a regular 
speed bump of ERP implementations. "There are 
often surprises lurking in legacy systems and 
processes" says James McCullough a former CIO 
with Delta Airlines [Ref. 16] McCullough says of 
an ERP implementation "We thought we understood 
how the previous system worked...but when we really 
got down to it, we found it wasn't like we 
thought." 

Organizations attempt to customize packages. 
Customizing packages should be a last resort in 
rapid-implementation plans, as the practices 
included in these plans are usually better than 
existing practices. However, in the military we 
often get locked into processes that we would 
like to change due to Eederal laws and 
regulation. [Ref. 17] 

Assumption that careful planning will lead to 
success. It takes vigilant monitoring of 
detailed goals, the committed involvement of 
executives and workers alike, a focus on customer 
needs and the careful building of a business case 
for the endeavor. [Ref. 17] 

The organization identified the new or 
destination architecture too late. Architecture 
in this passage refers to designing the system 
prior to determining the business direction or 
interrelationship and processes that must occur. 
[Ref. 10] 
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The information from the back end of ERP does not 
always make it into e-commerce (Web-based 
portals, front-end system) applications. [Ref. 
18] 


Difficulties with defining uniform data fields 
and ensuring data integrity. The result is IT 
departments can not accurately track their e- 
commerce data in their ERP systems and can not 
push information from ERP to e-commerce 
applications. [Ref. 19] 

Implementation takes longer than planned. The 
average ERP implementation takes between one to 
three years. "Real transformational ERP efforts 
usually run between one to three years, on 
average." [Ref. 20] Do not focus on how long it 
takes to implement the program; rather focus on 
why you need it and how you will use it to 
improve your business. Note: ERP 
implementations have gotten quicker. This comes 
from a 1999 case study. 

ERP has hidden costs that can result in budget 
overrun. [Ref. 20] Training, integration and 
testing, data conversion, data analysis, and 
post-ERP depression are just some of the hurdles 
that must be jumped in an ERP implementation. 
Acquisition overruns are still common in ERP 
implementations today. However, underestimate 
the cost to upgrade the IT infrastructure support 
is an overrun that is common but less publicized. 


Planners do not allot enough time in the work 
plan to deal with vendor problems. [Ref. 6] 


Most enterprises end up with incompatible 
technical architectures. Two most contributing 
factors to this are: 1) Bad decisions on how to 
handle legacy systems and 2) IS personnel take 
too long to come up with a decision about 
technical architecture and then the end-user 
community goes ahead without the Information 
Systems department involvement. [Ref. 10] 


Companies do not budget or plan for the costs of 
new IT skills and infrastructure in addition to 
the ERP package implementation. The technical 
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audit helps indicate the cost of migrating to ERP 
packages. [Ref. 17] 

• Most companies do not have good change management 
resources. [Ref. 17] 

B. KEY SUCCESS FACTORS 

The factors below were recurring themes in my 
literature review. If you put a "did not" in front of the 
following key success factors, the result would be 
additional things that could be added to the list of 
mistakes an organization can make during an ERP 
implementation. The things that should be done are as 
follow: 

• Plan prior to implementation. Plan for actual 
rollout of the new system early on in the project 
cycle. Perform an IT readiness assessment to 
determine if the necessary IT infrastructure is 
in place to make sure each site can handle the 
new system. [Ref. 21] 

• Users should conduct a rigorous internal audit 
before selecting application packages to ensure 
package-readiness and to facilitate the package 
selection and implementation process. [Ref. 22] 

• The various architectures must be established and 
agreed-upon prior to starting work on the first 
application. All system developers should employ 
this architecture as a framework for their design 
efforts. [Ref. 10] 

• The organization must conduct a thorough review 

of business and technical audit prior to 

selecting the ERP package. The package you 

choose should be based on business goals rather 
than desirability of features. [Ref. 10] 

• Perform a Legacy Audit where the existing 
applications are divided into three categories. 
1) Maintain, 2) Maintain and interoperate, or 3) 
Replace with new solutions. [Ref. 2] 
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Companies need to consider the practicality (cost 
and complexity) of their real-time requirements. 
Companies need to decide whether to focus on a 
unified mega-center approach or on distributed 
islands of automation. [Ref. 22] 

An ERP package should be viewed as a framework 
capable of supporting targeted niche solutions. 
The corporate project team should determine the 
required integration for each division and 
evaluate existing working solutions as well as 
targeted niche alternatives. [Ref. 22] 

Form an effective project team and establish 
effective communication mechanisms up, down, and 
across the organization. [Ref. 22] 

The project team must have representation from 
senior management, application package vendor, 
the systems integrator, the database vendor, and 
the hardware/server vendor. [Ref. 22] 

A system integrator should be used for large ERP 
projects. [Ref. 16] 

Consider the presentation tier, application tier, 
and database tier when designing the architecture 
of ERP packages. The separation of the 
presentation, application, and data layers 
(either physically or logically) has become the 
accepted paradigm for building deliverable, 
modular, and updateable client/server 
applications. Good application design, with 
emphasis on reducing network input/output is 
critical to success in client/server 
environments. Additionally, selecting scalable 
and high-performance servers and tuning them 
properly is also essential. [Ref. 22] 

Users should choose infrastructure components 
(hardware, DBMS, operating system) with the 
broadest market acceptance. They will have the 
broadest potential "integration tool set" from 
which to choose. [Ref. 23] 

Users should attempt to run all operational 
applications against a single operational data 
store because this provides for the best or most 
elegant integration. If this is not possible the 


43 



user should focus on the openness of the 
applications data model and the underlying 
infrastructure platform. [Ref. 22] 

Ensure extensibility of the system. [Ref. 22] 

Users should anticipate the need to extend ERR 
packages to data warehouses and pay particular 
attention to the infrastructure requirements. 
[Ref. 12] 

Develop a quantifiable business case. Establish 
concrete goals for the business processes you 
want to improve and calculate the expected 
benefits to be realized from these improvements. 
[Ref. 20] 

Define best practices. Identify key migration 
points and the precise type and timing of change. 
[Ref. 21] 

Strictly monitor implementation schedules and 
costs. Once rollout actually begins, all 
milestones should be carefully tracked, measured 
and rechecked to ensure that scheduled changes 
were made on time and on budget. [Ref. 21] 

Cross-cultural training. Make sure that all 
affected people are provided with training on the 
new program. [Ref. 21] 

Rigorous tracking of deliverables. Identifying 
and then relentlessly tracking the complex web of 
incremental milestones is critical to the success 
of a project. [Ref. 21] 

Access to all tools should be accessed from one 
portal. Portals can be customized based on the 
level of user or all users can see the same menus 
but with access safeguards built-in. A single 
access point can also be a security feature. 
[Ref. 24] 

Map out the functions that an integrated system 
must perform. [Ref.17] 

Articulate expectations before implementation. 
What will the project's stakeholders say are the 
attributes of the new environment in a year? 
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Where are the gaps in the plan? What conflicts 
of opinion exist today? [Ref. 17] 

Do not change too much at once. Major change 
requires an evolutionary approach. Do not 
overwhelm your organization with a system that 
has more functionality than you absolutely need. 
Consider a phased rollout and shoot for short 
wins to generate momentum during the project. 
[Ref. 17] 

Keep to the basics. Resist customizing the 
software or including optional features ... ways 
aim high enough to make a difference, but not so 
high that the target will be missed," says Jorge 
Taborga, vice president and CIO of Bay Networks 
Inc. [Ref. 17] 

Do not let technical problems dominate the 
project's time. Create a dedicated staff 
position for change management within the 
organization. Use your best and brightest people 
on the change team. [Ref. 17] 

View ERR implementation as a business initiative, 
not an IS initiative. [Ref. 18] 

Keeping an integration project in-house can offer 
the freedom to find creative solutions to 
integration problems. Hacking through an 
integration process in-house lets CIOs experiment 
with various integration methods and 
architectures." [Ref. 18] 

Do not be afraid to hire out. [Ref. 18] 

ERR implementations often leave the company still 
in a position where it cannot share information 
horizontally. These companies have to figure out 
how to connect their internal e-commerce and ERR 
applications outside of the enterprise. In the 
military, we would be concerned about possibly 
being able to share information in a joint 
environment. [Ref. 18] 
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Figure 10 below is a summary of the key success 


factors for any enterprise information system 
implementation. 


ERP Key Success Factors 

■ Conduct a rigorous Internal audit before selecting 
a^lication packages to ensure "package-readiness" and to 
facilitate the package selection and in^lenentation. 

• Establish architectures prior to starting mirk on the 
first application. This architecture should be franemirk 
for all design efforts. 

■ Budget/plan for the costs of new IT skills and 
infrastructure in addition to the ERP package 
inpleinent atio n. 

■ Create an effective project team with representation from 
stai^eholders across the organization. 

• Establish effective comminication mechanisms down, 

and across the organization. 

■ Choose infrastructure components (hardware, DBKS, 
operating s^tem) with the broadest market 
acceptance.this facilitates easier integration later. 

■ Consider the presentation tier, application tier, and 
database tier idien designing the architecture of ERP 
packages. 

■ Attempt to run all operational applications against a 
single operational data store. If this isn't possible, 
focus on the openness of the applications data model and 
the underlying infrastructural platform. 

■ Anticipate the need to extend ERP packages to data 
warehouses and pay particular attention to the 
infrastructure reguirements. 

■ Strictly monitor inplementation schedules and costs. 

■ Hap out the functions that an integrated system must 
perform. 

■ Articulate expectations before implementation. 

■ Don't change too much at once. 

■ Don't let technical problems dominate the project's time. 
Create a team to trouble-shoot problems. 

■ Don't be afraid to hire out. 

• Resist customizing the software or including optional 
features.in other words stick to the basics. 


Figure 10. Traditional ERP Key Success Factors 
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Figure 11 below is a condensed list of the things that 


I consider the most relevant to the TFAS project. 



Consider ttie presentation tier, application tier, and 
database tier when designing the architecture. This 
involves not only separate servers for the different 
tiers but also modularizing software by function for 
each tier additionally. 

Establish architectures prior to starting work on the 
first application. This architecture should be 
framework for all design efforts. (Appears frcm 
documentation as if this could have alreac^ occurred. 
Beware of possible conseguences.) 

Choose infrastructure components (haribrare, DEBIS, 
operating system) with the broadest market 
acceptance.this facilitates easier integration later. 
Additionally, the more coiimon the components, the 
easier it will be to get support from the 
manufacturer...especially 5 years down the road. 

Beware that integration of existing systems could be 
the biggest hurdle to this implementation. This is 
less of a concern with the TFAS but more of concern 
with the DIHRMS. Will the TFAS architecture be 
compatible with PeopleSoftB software? 

Beware that in Corporate ERP implonentations, 
information from the back end of ERF doesn't always 
make it into the front end systems. This would be 
catastrophic for the TFAS initiative; test early and 
often. 


Figure 11. TFAS Key Success Factors 
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The lessons listed while seeming universal are not 
applicable to all enterprise system implementations. The 
mistakes and success factors are not all applicable to 
military enterprise systems. They are not even universal to 
all corporate enterprise implementations. It should be 
noted that this list is not all-inclusive. Absent from 
most of the literature I reviewed were concerns for 
building operational type security features into the 
enterprise system. Additionally, there was little in the 
lists on communication platform mistakes. The unique 
requirements of military systems and the environments in 
which our systems must work in are part of the reason for 
this. I am sure that there are other areas that I have not 
covered in this thesis. Thus, those who know the TFAS 
system the best must add to this list of key success 
factors. 
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V. 


EVALUATION OF TFAS'ARCHITECTURE 


Mark Goodyear [Ref. 10], states that the four main 
components of effective enterprise information architecture 
are the business solutions, application architecture, 
technical architecture, and the communications platform. 
This thesis only attempts to evaluate the technical 
architecture of the TFAS initiative. 

The business solution architecture is a combination of 
the environment, business requirements and data 
architecture. Goodyear says, "When it comes time to decide 
what technical architecture to use, many of the answers are 
found by looking at the business solutions architecture." 
[Ref. 10] The applications architecture refers to those 
components that provide the automation support for a 
business function or activity not including the platform. 
The technical layer is comprised of the (1) execution 
architecture, (2) development architecture, (3) operations 
architectures, and (4) the infrastructure and system 
software layers combined. The platform architecture 
involves the "servers, workstations, operating systems, and 
networks." [Ref. 10] Figure 12 is an illustration of how 
these different architectures of the technical layer relate 
to each other and, as a whole is the foundation of the 
enterprise application. 

The C4ISR Architecture Framework states that the three 
types of architectures as operational, systems, and 
technical. "The C4ISR Architecture Framework provides 
guidance on describing architectures." [Ref. 5] The C4ISR 
puts much focus on architecture views or diagrams and the 
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tools available to build effective diagrams. Chapter III 
even lists six steps to building architecture. However, 
reference ten, "Enterprise System Architectures: Building 
Client/server and Web-based Systems" was used as the basis 
of most of the definitions in this thesis because of this 
thesis' focus on corporate and enterprise architecture. 



Figure 12. Relationship Among the Technical Architectures 

From Ref. [10] 

A. TECHNICAL ARCHITECTURE 

1. No Development Architecture 

No development architecture was included in any of the 
preliminary documents or in the study conducted by the two 
consultants KPMG and PricewaterhouseCoopers . A formal 
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technical architecture study was completed and published by 
KPMG prior to September 31, 2000 (FY' 00). However, this 
study has not been posted for public viewing and was not 
provided, as requested prior to the completion of this 
thesis. Therefore, this thesis can only evaluate the 
currently published architectural information. I am unaware 
of whether development architecture was included in this 
technical study. The TFAS documentation does mention that 
the TFAS will be accomplished within the TAFIM and JTA 
architectural standards. Figure 13 and figure 14 below are 
the JTA and TAFIM models that TFAS has to comply with. 
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Figure 14. TAFIM Model From Ref. [26] 
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However, I am not thoroughly familiar with these two 
models, thus this thesis will not evaluate the TAFIM and 
JTA models and how they apply to the TFAS. The TFAS 
designers have listed the following qualities [Ref. 2] that 
the TFAS architecture will have to take into consideration 
to meet TAFIM and JTA standards. 

• Interoperable - allowing connectivity and 
interchange of information among information 
resources on the network, application, 
presentation and data levels without special 
connections, procedures or other intermediate 
translation, and gateway devices. 

• Transparent - providing the user with a virtual 
information services environment so the user does 
not need to know where the applications and data 
reside. 

• Scaleable - supporting information system 

environments from large, fixed facilities, and 
networks to hand-held and disconnected devices in 
any clime or place. 

• Responsive - guaranteeing assured services, 

quickly available, when and where needed 
worldwide. 

• Secure - implementing multiple security policies 
and assuring required information systems and 
communications security and availability. 

• Easy to use - providing intuitive interfaces 

tailored to the user's preferences where 
possible. 

• Flexible and maintainable - architecture must 

allow quick migration and integration of new 
applications and technology (e.g., through the 
use of standards-based and vendor-independent 
approaches). 
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Reliable - architecture must support alternative 
resource and service access or graceful 
degradation. 


Affordable 
value for 
services) 
consistent 


- architecture must provide the best 
required services (and only required 
in the most efficient way available 
with mission needs. 


Evolvable 
methods, 
evolve to 


architecture must 
metrics, tools, and 
new capabilities. 


include special 
environments to 


Survivable - 

information 

requirements 


Architecture must ensure essential 
is available to meet mission 
under varying conditions. 


Although, not included in this list, information 
integrity and operational security are two qualities that 
all military system architecture should have as 
cornerstones in addition to the list above. 


Figure 15 is a guide for understanding the development 
architecture or environment and an illustration of things 
that should be included. 
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Figure 15. Development Architecture From Ref. [10] 
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Mark Goodyear [Ref. 10] raises one major concern about 
the development architecture and environment. He states as 
follows: 

In the client/server and netcentric environment 
it is vital to get the development environment 
right the first time. Changing the development 
environment when construction is fully staffed 
may entail serious disruptions and expensive loss 
of productivity. The purpose of the development 
architecture is to support the tasks involved in 
the analysis, design, construction, and 
maintenance of business systems as the associated 
management processes. [Ref. 1] 

The purpose of the system architecture process is 
to provide integral technical overview and 
consistency, to maintain the integrity over time, 
and bridge the gap between the policy and 
planning process and the product creation 
process. [Ref. 16] The technical architecture 
provides a standard and consistent approach for 
creating or modifying a system. Normally a 
technical architecture will have three parts: 
the execution architecture, the development 
architecture, and the operations architecture. 
Having these three architectures as part of the 
overall technical architecture provides: "a 

common background for information system 
personnel, a more rapid delivery solution and a 
reduced impact of change. [Ref. 10]" 

Muller [Ref. 27] indicates that the key issues in 
ing systems architecture plans are: balance, 

stency, integrity, simplicity, and elegance. The 
to be balanced by the system architecture process 
external and internal requirements, short term needs 
long term interests, efforts and risks from 


draft 
cons i 
goals 
are : 
and 
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requirements to verification, detailed designs mutually, 
and value and costs. 

Figure 16 demonstrates that as project complexity and 
degree of business process increases so does project risk 
and cost. 


Zone 1 Zone 2 Zone 3 



Figure 16. Complexity Increases with Increased Process 

Change From Ref. [6] 

Prior to implementing any system, an organization 
should assess its current capabilities and its desired 
capabilities. Figure 17 was created by 

PricewaterhouseCoopers [Ref. 6] to assist companies in 
determining where they are in standard enterprise and e- 
commerce terms and where their desired changes will take 
them. Using this model as a basis, I would rate the 
Marine Corps' current system as a borderline Nonintegrated 
System and Limited/Single Function ERP . The TFAS 

implementation is only a channel enhancement that better 
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positions the Marine Corps to move to the value-chain 
integration arena. The Marine Corps current status can be 
seen in Figure 18. It is highly unlikely that the DoD or 
the Marine Corps will ever achieve or even desires to 
achieve the industry transformation phase. However, the 
idea of achieving an integrated Enterprise ERP system is 
something that should appeal to the U. S. Marine Corps and 
the other military services. An integrated Enterprise ERP 
system is one in which human resources, finance, supply and 
logistics, and other areas such as recruiting are all 
interoperable and connected allowing for richer knowledge 
and decision support. If this phase could ever be 
achieved, the idea of convergence would then be imaginable, 
where all the services integrated ERP systems could be 
linked together for the sharing of information within DoD 
and amongst contractors. 


No E'Business Channel Value-Chain Industry Convergence 

Capabilities Enhancement Integration Transformation 



Eigure 17. ERP evolution Erom Ref [6] 


57 













Ho E‘Busine$5 
Capabilities 


Channel 
Ebkmc emenl 


V«lu« Cham 
hftegration 


Industiy 

Transfbimation 


Commgmce 


Greenfield 


Hon Integrated Systems 


LinutedfSingle- 
Function ERP 


Inte^eted Business 
System EI^ 


Integrated Ehteipiis e 
ERP 


Figure 18. The TFAS Evolution After Ref. [6] 


B. OPERATIONAL ARCHITECTURE 

"The operations architecture is a combination of 
tools, support services, procedures, and controls required 
to keep a production system up and running well." [Ref.10] 
The primary users of the operations architecture are 
"system administrators and production support personnel." 
[Ref. 10] 

Figures 19 and 20 below are listed in the TFAS 
documentation as operational architecture diagrams. They 
actually represent more of a data flow rather than 
operational architecture. However, since these are the 
only "operational architecture" diagrams found in the 
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preliminary assessment, we will evaluate the information in 
these diagrams at this time. 

1. Current Operational Architecture 

a. Observations from the "As—IS" Operational 
Architecture 

The "As-Is" Operational architecture tells the 
same story as the situational state diagram. This 
architecture shows interaction with the system to be 
limited to just two levels in the current architecture. It 
demonstrates the systems reliance on administrators to 
validate, authenticate, enter, and access data. 


Collect/Prepare/Approve 



Figure 19. "As Is" Operational Architecture From Ref. [2] 
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2 . Proposed Operational Architecture 

a. Observations from the "To-Be" Operational 
Architecture 

The "To-Be architecture is simply a demonstration 
of the five levels of interaction with the current system. 
The purpose of the TFAS is to spread the responsibility for 
keeping records up-to-date from the administrator to the 
individual Marine and others in the chain-of-command. The 
operational architecture accurately portrays this concept. 
The approval blocks show some of the controls that will 
disperse throughout the system at different levels. 



Figure 20. "To Be" Operational Architecture From Ref. [2] 
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C. EXECUTION ARCHITECTURE 

The Marine Corps describes the current environment. 
Figure 21, as a "state of the art, distributed client- 
server system" that has evolved in the last three years 
through technology refreshments." [Ref. 2] It is true that 
the current architecture has client/server capabilities. 
However, the majority of data input into the system is 
still based on batch unit diaries. Information can be 
retrieved via UD/MIPS online, but that data is not always 
the most current due to the processing time of unit 
diaries. The TFAS documentation says that the current 
system is "providing users access to information, 
resources, and capabilities never experienced within the 
realm of Marine personnel and pay administration." [Ref. 2] 
While this may be true, the output from UD/MIPS probably 
falls somewhere between the data and knowledge realm. It 
has been two years since I last used UD/MIPS and therefore 
am unaware of whether it has been updated to provide richer 
data that could better support decision support. 

The TFAS is intended as mainly a garrison solution for 
Marines, and the execution diagrams below reflect that 
view. However, for the TFAS to achieve the goal of being 
compatible with Operational Maneuver from the Sea and have 
the reach back capability that this will require deserves 
attention now in the early stages of the program. With the 
bandwidth requirements of the TFAS, it is certain that 
solutions for the deployed, bandwidth-limited environment 
must be developed to allow the smallest administrative 
footprint possible. Administrators can use UD/MIPS in a 
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deployed environment much as they do today to handle the 
bulk of the administrative workload. However, Marines will 
be used to having information at their fingertips in 
garrison and would have to adjust their routine or process 
for handling administration while embarked on ship for 
example. However, options can be built into the system to 
make the transition from garrison to austere conditions 
easier for the individual Marine. Some of those options 
include decoupling the information system to facilitate e- 
mail transactions to the PAG rather than the keystroke-by- 
keystroke environment they would encounter via the Web; A 
cd-rom(s) with all Marine info could be deployed with the 
Marines to allow Marines to continue to access their info 
per the latest cd-rom update; or using secondary memory 
(cache) on shipboard servers or other computers to store 
data. Any of these solutions would minimize required 
bandwidth and interactivity with MCTFS servers/databases 
and PACs. Additionally, the use of multi-casting data to 
the PACS could reduce PAC interactivity with MCTFS servers 
and databases. 
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1. 


Level 1: The Individual Marine 


a. Desired End State 

Capabilities will be made available to individual 
Marines that allow them to submit pay and personnel-related 
information via telecommunications systems to central 
processing activities, identified as Personnel 
Administration Centers (PACs). Marines will primarily 
submit transactions via a Web-based, menu-driven 
application from a computer with Internet access. They 
will be able to access their pay and personnel accounts to 
review information and to submit required changes 
electronically, telephonically or via the mail without 
having to physically go to a personnel administration 
office. This capability will also be available from ships 
and the full range of expeditionary environments. [Ref. 2] 

b. Figure Depiction 

The individual Marine will be able to access 
information and report certain transactions via a computer 
with a Web browser. The Marine can also phone the Call 
Center and review information or submit transactions 
through the interactive voice response system (IVRS). In 
the event Marines need assistance, they will be able to 
talk directly to a call center representative who will them 
information and submit certain transactions on their 
behalf. Marines will also be able to get support in a 
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conventional manner through their small 
traditional reporting unit admin section. 


unit 


leader or 


[Ref. 2] 
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Figure 22. Individual Marine From Ref. [2] 

c. Analysis 

Success of the TFAS project depends upon success 
at this the first level. If the TFAS implementation works 

as pictured in this Figure 22, which shows the individual 
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of the 


majority of his 


own 


Marine taking care 
administrative needs with minimal guidance from his small 
unit leadership. Information from Marine individual 
records have already been pushed to the Web via MOL, the 
key is for Marines to have the ability to push information 
back . 

2. Level 2: Small Unit Leaders 


Figure 23 is a 
scheme. 


diagram of the level 2 execution 


Personnel 




Figure 23. Small Unit Leaders From Ref. [2] 

a. Desired End State 

The goal for small unit leadership is to be able 
to input Marine training information into the system while 
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providing oversight of individual Marine transactions. An 
abbreviated version of UD/MIPS should be in place so that 
unit leaders do not have to become experts with the current 
UD/MIPS that requires training and expertise for 
information input. 

b. Figure Depiction 

Small unit leaders will be able to remotely 
capture information with a personal electronic device (PED) 
similar to a personal digital assistant (PDA). The PED can 
upload information directly into MCTES via a significantly 
scaled down and abbreviated version of UD/MIPS designed for 
non-administrators or the full version of UD/MIPS located 
at the traditional reporting unit level. Transactions can 
also be keyed directly into the UD/MIPS. The PEDs can 
receive downloads from the small unit leaders simplified 
UD/MIPS or complete UD/MIPS, and allow users to view pay 
and personnel information in a highly portable 
configuration. Small unit leaders will also have the 
capability to review pay and personnel information on their 
Marines. [Ref. 2 ] 

c. Analysis 

The idea is to use PEDs to record information at 
training events and then go back and hot-sync the PED to a 
computer with a scaled down version of the UD/MIPS. This 
appears to be a great idea, but there is little information 
in the preliminary documentation that discusses how this 
will be accomplished. I am not sure how feasible an 
abbreviated version of UD/MIPS is either. 
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3. Level 3: Battalion and Squadron Commands 

a. Desired End State 

Commanders at the battalion/squadron and above 
levels will retain an administrative capability to collect, 
provide quality control and forward personnel and pay- 
related information to the Personnel Administration Center 
(PAC) for final processing. This will be primarily focused 
on command-originated data, but the capability to forward 
any information on behalf of the individual Marine will be 
available. These administrators will also review feedback 
reports on data submitted to a PAC by individual Marines 
via Web applications, toll free telephone services or the 
mail. This will enable the commander to stay informed of 
the changing personnel status of his or her Marines. The 
commander will have electronic access to pay and personnel- 
related information on Marines to facilitate situational 
awareness and unit-level decision making. 

b. Figure Depiction 

Figure 24 simply shows that at the battalion and 
squadron level, administration will be conducted the same 
as it is now. The only changes are that the number of 
transactions that will be processed at this level will be 
significantly streamlined. The squadron or battalion will 
have oversight over certain functions that only happen 
above the company level and not requiring (PAC) approval. 


68 



Rasomel 

Admnshslicn 

Cenb- 



Figure 24. Command (Battalion & Squadron) From Ref. [2] 

c. Evaluation of Desired End State 

This is how things are done today with fewer 
transactions and responsibility. I see no problems with 
acquiring this level of the TFAS. 
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4. Level 4: Personnel Administration Center 

a. Desired End State 

The Marine Corps plans on establishing a minimum 
of three Personnel Administration Centers (PACs). The 
consolidation of Marine Corps administrators would 
eventually end at the PAC level. Administrators would 
migrate from Regimental/Groups to Division/Wing and then 
finally to base or PACs. With each consolidation, the 
number of administrators required to handle the 
administrative would be the level at which Marine Corps 
administrators would be consolidated. 

b. Figure Depiction 

The PAC will have the ability to receive 
traditional reporting via the UD/MIPS in addition to 
processing required information from Marine self-service. 
One of the PACs would host the TFAS call center for handle 
all call center functions. A second call center would be 
the alternate call center that would be operated when the 
primary call center was inoperable. Each PAC would focus 
primarily on serving Marines whether active duty, reserve, 
or retired in their region of responsibility. However, a 
PAC could process information on any Marine during times of 
system failure. The PAC users would have access to 
information in the operational data store enterprise (ODSE) 
database . 
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Figure 25. Personnel Administration Center From Ref. [2] 

c. Analysis 

The PAC is the key to the success of the TFAS 
initiative. This is a totally new level that incorporates 
most of the administrative responsibility that battalions 
and squadrons previously held plus the additional 
responsibility of handling call center and Web input. 
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5. 


Level 5: Higher HQ and Disbursing 


a. Desired End State 

At this level Manpower and Reserve Affairs will 
retain functional sponsorship for personnel administration 
and the Deputy Chief of Staff for Programs and Resources 
will retain functional sponsorship for pay. 

b. Figure Depiction 

Figure 26 is a replica of the level four diagram 
minus the call center. 
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Figure 26. Higher HQ/Disbursing From Ref. [2] 
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Administrators at this level would not perform a function 
in the direct support of the individual Marine, although 
pay and administration functions based on the input data 
into the system would occur here. This is also the level 
at which strategic administrative functions would occur, 
much the same as they occur today. 

c. Analysis 

Nothing changes at this level. All relationships 
remain virtually the same. Responsibilities for oversight 
of functions do not change. 

D. TRANSACTION STATE DIAGRAMS 

1. Analysis 

As you would imagine, there are not many differences 
between the "As-Is" and "To-be" transaction state diagrams. 
Figures 27 and 28. Simply stated, TFAS is simply adding an 
additional front-end to the current system. However, there 
is a difference in the two diagrams. The first difference 
is that in the "As-Is" architecture a data entry must be 
approved prior to entry into the system whereas with the 
"To-be" architecture process rules must be coded and 
installed into they system to differentiate between entries 
that must be approved and entries requiring no approval. 
Additionally, the "As-Is" diagram appears to be simpler and 
more timely than the TFAS transition diagram, but it does 
not show the levels of bureaucracy that occur between an 
event and its initial entry or key punch into the system. 
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Figure 27. "As Is" Transition State Diagram From Ref. [2] 
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Figure 28. "To Be" Transition State Diagram From Ref. [2] 
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VI. CONCLUSION RECOMMENDATIONS 


A. PROJECT CONCEPTION 

The TFAS initiative is the Marine Corps initiative to 
reengineer its manpower intensive human resource system by 
adding an individual Marine self-service capability to the 
current system. It is envisioned that this capability will 
allow the Marine Corps to increase its tooth to tail ratio 
and increase the level of customer service to the 
individual Marine. This thesis evaluated previous 
enterprise system implementations searching for common 
mistakes and key success factors that could be applied to 
the TFAS implementation. As stated previously, corporate 
and military human resource systems are similar in 
functions but different in the environments in which they 
must work. Similar functions include but are not limited 
to: insurance, income tax, tuition assistance, pay records, 
benefits, and audits. The differences, operational security 
and bandwidth-limited environments, are why modularity, 
loose coupling, and operational security must be built into 
military systems. 

B. SUMMARY OF ANALYSIS 

All of the TFAS documentation that I reviewed focused 
on getting the MCTFS data to the Web and on giving the 
Marine access and responsibility for updating some of that 
data. None of the documentation talked about creating 
knowledge or increasing the decision support capability 
from that data, an aspect normally associated with an ERP 
system. Absent in the documentation is talk about someday 
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linking this enterprise information system to other 
enterprise systems within the Marine Corps such as supply, 
recruiting, etc. Thus, the TFAS initiative in all reality 
has the appearance of more of an e-business (Web) 
implementation rather than an ERP project. 

The TFAS leadership characterized their overall 
strategy for proceeding with the TFAS, as a strategy of "do 
no harm." [Ref. 2] As the documentation in this thesis 
has shown, the TFAS initiative represents only a small step 
or enhancement of the status quo. However, this small step 
is all that was required to meet the original goal of CMC 
to decrease the ratio of administrators to Marines, thus 
allowing the assignment or reassignment of more Marines 
into combat arms military occupational specialties (MOSs). 

Even without the new TFAS front-end and customer 
service center, the initiative has already paid dividends 
for the Marine Corps. The TFAS initiative forced the 
Marine Corps to look at its processes, many of which had 
not been modified since they were implemented nearly 20 
years ago when the MCTFS was first brought online. 
Streamlining the processes alone has allowed the Corps to 
accomplish its goal of reducing Corps-wide the number of 
administrators required to support the fleet. Earlier this 
year, the Marine Corps migrated most administration 
functions and administrators from the squadrons and 
battalions to the Marine Aircraft Group (MAG) and 
regimental level. 

A successful implementation of TFAS will see 
administration functions consolidated at the Marine Corps 
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Base or PAC level. Although no information has been 
provided as to the exact number of administrators that can 
be retrained or assigned to the fleet in other more 
critical MOSs, the economies of scale created as 
administration is consolidated at higher levels should be 
significant. Also, remember that 1070 administrators were 
reassigned during the first year of the program, and we can 
see that the Corps has already started reaping the benefits 
of the Commandants' vision. The TFAS simply attempts to 
leverage existing technology to further multiply the 
manpower and cost savings while introducing the customer 
service concept in addition to the old focus of 
functionality to Marine Corps administration. 

The key drivers in the choices made in the TFAS 
planning process were cost and risk. The initiative as 
currently defined is virtually risk free and at a projected 
cost of near $30 million. The implementation of TFAS over 
a period of eight years allows the Marine Corps to use 
money that would normally have been used for upgrades to 
the Unit Diary/Manpower Information Processing System 
(UD/MIPS), thus a basic reallocation of money. The TFAS is 
also a cheaper alternative than the status quo over a five- 
year period according to PricewaterhouseCoopers 
calculations. It can, however, be argued that for the same 
$30 million or less, the recommendations of 
PricewaterhouseCoopers could have been accomplished in a 
shorter period of time. Human Resource self-service 
technology is already a proven technology with most 
corporate implementations having few or little 
implementation problems. However, most corporations 
implement self-service technology and ERP systems to 
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achieve the maximum gains in productivity to get the most 
return on investment. 

Looking at the TFAS documents provided and reviewed 
for this thesis: the three PricewaterhouseCoopers' studies, 
the Marine Corps Vision and End State document, and the 
preliminary assessment, it is not possible to predict with 
absolute certainty that this will be a successful 
implementation. I see no problem with the preliminary 
architecture; the diagrams demonstrate the picture of the 
TFAS as expressed in the TFAS vision. However, some 
diagrams were missing and those diagrams present were all 
very high-level and thus do not portray the level of detail 
necessary to make a more detailed analysis. The TFAS is of 
limited scope, the level of complexity is low compared to 
corporate implementations, and call center and Web-based 
portal technology is mature, thus TFAS appears on the road 
to success. Additionally, the familiarities of the 
implementation team with the MCTFS, the UD/MIPS and the 
other back-end and middleware systems currently in-place, 
and the involvement of all stakeholders in the 
implementation process are all complementary to the TFAS 
implementation. The TFAS implementation appears to have a 
solid project management plan based on a balanced 
integration plan. 

This thesis will not be as beneficial to the TFAS 
leadership as it would have been if the study had been 
completed prior to actual execution of the plan. However, 
the Marine Corps can leverage the lessons learned from 
other implementations and this thesis to avoid pitfalls 
that could be lurching in the projects future. Lessons 
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learned from corporate implementations can be beneficial to 
the TFAS leadership. However, some of the lessons learned 
focus on a time prior to implementation and thus can only 
be used as a reflective area of caution. Some of these 
issues will be further developed in the concerns and 
recommendations portion of this thesis. 

My study shows that there is no standard set of 
metrics by which an ERP or enterprise system implementation 
can be measured a success. Success or failure should be 
defined prior to implementation by the goals or vision for 
the project. Organizations determine their own metrics, 
such as cycle time and Full Time Equivalent (FTE's) 
improvements. However, in a military organization, a 
system should always be evaluated for its impact on 
operation security, something that could be overlooked in a 
human resource enterprise implementation. The key is 
whether the organizational goals and vision are met. 
However, the organization must establish a baseline of 
existing process metrics to compare with post-ERP process 
metrics. This project should satisfy the stated goals of 
the leadership. 

C. CONCERNS AND RECOMMENDATIONS 

My biggest concern with the TFAS initiative is that 
the Defense Integrated Military Human Resources System 
appears to be poised to duplicate the TFAS effort. If this 
turns out to be the case, the DIHMRS, because it is a DoD 
initiative will have precedence over the TFAS. Thus, a lot 
of time and money may have been spent needlessly. Based on 
the description of TFAS found in reference three as quoted 
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earlier there will definitely be a duplication of function 
of the TFAS and the DIHMRS. A second issue with this 
duplication is the possibility that the MCTFS, the Marine 
Corp's back end system, will not be addressed as part of 
the DIHRMS initiative, an assumption that the TFAS 
initiative relies on heavily in its preliminary assessment. 

Another concern is that TFAS leadership has proceeded 
with the TFAS implementation prior to designing and 
finalizing all architectural decisions. One of the key 
success factors from Chapter IV says do not start on any 
applications until the architectural design has been 
completed. It appears that the TFAS implementation has 
violated this rule. The reason giving for proceeding with 
the TFAS implementation prior to the completed 
architectural study is that many of the updates and actions 
fell in line with the UD/MIPS upgrades. The risk of doing 
this is that the TFAS architecture will not be consistent 
and that integration will be more difficult later on in the 
TFAS process. The architecture is the foundation of 
everything that happens with the project, and this alone 
introduces considerable risk into the project. Having a 
technical architecture provides many benefits to the 
consistency of a project, including as mentioned earlier in 
the thesis, a common background for information system 
personnel, more rapid delivery of solutions, and reduced 
impact of change. [Ref. 10] 

A third concern for the TFAS implementation is the 
lack of depth of explaining some of the concepts of how the 
TFAS will work with PDAs/PEDs and be programmed for use at 
levels two and three to be able to input information into 
the TFAS system. There are examples in industry of 
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companies using PDAs in this fashion; however, it should 
not be assumed that this would be an easy thing to 
accomplish. Will we contract this out to an established 
contractor or will it be done in house? Does PeopleSoft 
have the capability to accomplish this with the DIHRMS 
initiative? These are all questions that should be 
answered. Additionally, what is the concept for the TFAS 
during combat operations that will allow the TFAS to 
support OMFTS? Will we rely on UD/MIPS as we currently do 
or do we attempt to use the Internet from the battlefield 
to input into the TFAS? 

There is little discussion as to who will create the 
software for the TFAS. It suggests that ITD-KCC will 
create the software applications as well as implement the 
entire project, but this is not clear. The software for an 
enterprise system is even more important than the hardware, 
thus I would like to have seen more information about this 
in the preliminary assessment. As defined earlier in 
chapter two, modularity and loose coupling should be used 
as a part of the software building process. The goal 
should be for the system to be interoperable and non¬ 
hardware specific. This will pay dividends in the future 
when the DIHMRS migration must occur and when hardware is 
being chosen for PEDs. Additionally, consideration should 
be given to how the system will work in bandwidth-limited 
environments, such as on ship. Caching could be built into 
the system or downloading information to disks to make 
required connection to the server as limited as possible 
from austere, bandwidth-limited situations. 

There are other issues that have less to do with the 
TFAS and more with PeopleSoft who has received the DIHMRS 
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contract. PeopleSoft is being sued by a subsidiary of 
CIGNA Corp, Connecticut General Life Insurance Company. 
PeopleSoft is being accused of botching the ERP software 
development and failure to properly implement the system. 
[Ref. 9] PeopleSoft stated [Ref. 9], "It is unfortunate 
that for internal reasons, CIGNA was unable successfully to 
adopt our software, but this was not related to the quality 
of the software or services provided by PeopleSoft." I 
would recommend that the Marine Corps push PeopleSoftS 
(DIHRMS) migration back until it has been successfully 
deployed in the other services. Since the Marine Corps has 
already proceeded with the TEAS, if DIHMRS migration proves 
to be unsuccessful in other parts of DoD, the Marine Corps 
can fall back on the TEAS and delay migration until the 
problems have been worked out. 

PeopleSoft is a company that is growing quickly. 
Some question their ability to sustain this growth and 
support all of their responsibilities. With the size and 
complexity of DoD, PeopleSoft might have problems with the 
DIHMRS migration. PeopleSoft has won several high profile 
contracts in recent months to include the IRS and the 
DIHRMS contract both of which have been promised product 
delivery within one year. PeopleSoft has 2000 current 
customers who have requested upgrades to PeopleSoft 8, of 
which only 200 have been upgraded as of September 1, 2001 
and projections of only an additional 500 being up and 
running by next year. Delaying implementation until the 
end will be a good risk mitigation strategy for the Marine 
Corps. It is too late for the TEAS project to completely 
change direction. Therefore, if I were the program manager 
for the TEAS project, I would proceed with the project as 
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planned but tread cautiously. I would come up with a 
contingency plan to address the MCTFS as a risk mitigation 
strategy just in case this thesis is correct that DIHMRS 
and TFAS do duplicate effort. I would perform a second 
review of the TFAS architecture study to ensure the TFAS 
applications are built on a solid basis. 


D. Further Research 

There was not enough information available to conduct 
a thorough analysis of the TFAS architecture. The TFAS 
leadership may have already negotiated many of the concerns 
discussed in this thesis. I am sure that there is more 
documentation that I was not privy to that could lend more 
credibility to a concern or provide the answers to 
questions that would make the concern invalid. Research 
should be conducted on a comparison of the DIHMRS and the 
TFAS to determine if the assumptions of the TFAS leadership 
that TFAS is addressing areas different from the TFAS and 
that the DIHMRS will address the back end systems neglected 
by the TFAS are indeed true. Until this is accomplished, I 
think it is futile to study other areas of the program. 

However, once this has been completed the other areas 
that could benefit from further research are a review of 
any official technical architecture that goes beyond the 
preliminary documents reviewed in this thesis would be 
beneficial. The study of the security features of the 
TFAS and the communications platform are all areas ripe for 
study. A study of what it would take for the Marine Corps 
to have a truly integrated enterprise, e.g., tie supply, 
finance, human resource, all to one system where data from 
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anywhere could be moved anywhere in the enterprise is 
another area for study. 

Additionally, some type of comparison should be done 
to determine whether the quality of service to the 
individual Marine actually increases or decreases because 
of the TFAS implementation. In the short term there will 
probably be some degradation of service, especially during 
the period prior to Marine self-service coming online when 
administration is being consolidated at higher levels. 
Capturing and applying the lessons learned from the TFAS 
implementation to the DIHRMS implementation and future 
human resource implementations are areas that should also 
be considered. 
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